ElasticSearch性能优化详解

良好的索引结构设计是性能优化的基础：

分片数量优化

分片是ElasticSearch存储和搜索的基本单位，合理的分片数量对性能至关重要：

• 避免过多分片：每个分片需要内存和CPU资源
• 避免过少分片：限制了水平扩展能力
• 一般建议初始分片数量为节点数 * 1.5到节点数 * 3
• 每个分片大小控制在20-40GB较为合适

副本优化

副本提供高可用性和读取性能，但需要权衡存储空间和写入性能：

• 生产环境至少配置1个副本确保高可用
• 读密集型场景可适当增加副本数提高并发读性能
• 写密集型场景应控制副本数量，因为每个写操作都要复制到所有副本

索引生命周期管理

使用ILM(Index Lifecycle Management)管理索引生命周期：

• 热-温-冷架构设计（Hot-Warm-Cold Architecture）
• 自动滚动索引（Rolling Indices）
• 自动归档或删除旧数据

精心设计的映射可以显著提高索引和查询性能：

字段类型优化

为每个字段选择最合适的数据类型：

• 使用具体的数值类型，如integer而不是long（当数值范围允许时）
• 日期字段使用date类型而非字符串
• 对于枚举值，使用keyword而非text
• 对地理位置信息使用geo_point或geo_shape

分析器优化

为全文搜索字段选择合适的分析器：

• 根据语言选择特定语言分析器（如english、chinese等）
• 使用keyword分析器处理不需分词的字段
• 创建自定义分析器满足特定业务需求

Dynamic Mapping控制

控制动态映射以避免意外的字段创建：

• 设置dynamic: strict防止未在映射中定义的字段被索引
• 为预期的动态字段创建动态模板

{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "title": { "type": "text" },
      "content": { "type": "text" },
      "date": { "type": "date" },
      "user_id": { "type": "keyword" },
      "views": { "type": "integer" }
    }
  }
}

禁用不必要的功能

禁用不需要的特性可以节省资源：

• 对不需要全文搜索的字段禁用norms
• 不需要排序或聚合的全文字段禁用doc_values
• 对不需要搜索的字段设置index: false

索引模板可以自动应用预定义的设置和映射到新创建的索引：

索引模板使用场景

• 时间序列数据的滚动索引（如日志、指标）
• 多租户应用中自动创建的索引
• 确保所有索引使用一致的映射和设置

索引模板最佳实践

有效使用索引模板的策略：

• 使用组件模板(Component Templates)复用通用配置
• 使用优先级(Priority)控制模板应用顺序
• 设置index_patterns精确匹配预期的索引名称模式

{
  "index_templates": [
    {
      "name": "logs_template",
      "index_patterns": ["logs-*"],
      "priority": 100,
      "template": {
        "settings": {
          "number_of_shards": 3,
          "number_of_replicas": 1,
          "refresh_interval": "5s"
        },
        "mappings": {
          "properties": {
            "timestamp": { "type": "date" },
            "message": { "type": "text" },
            "level": { "type": "keyword" },
            "service": { "type": "keyword" }
          }
        }
      }
    }
  ]
}

选择合适的查询类型可以显著影响性能：

精确匹配查询优化

对于精确匹配场景：

• 使用term查询而非match查询
• 对多值精确匹配使用terms查询
• 对范围查询使用range查询

# 优化前
GET my_index/_search
{
  "query": {
    "match": {
      "status": "active"
    }
  }
}

# 优化后
GET my_index/_search
{
  "query": {
    "term": {
      "status.keyword": "active"
    }
  }
}

全文搜索优化

全文搜索查询优化策略：

• 使用match_phrase代替match查询（当需要短语匹配时）
• 设置合理的minimum_should_match参数减少低相关性结果
• 避免使用通配符前缀查询如prefix、wildcard，尤其是前缀通配符

# 优化全文搜索
GET my_index/_search
{
  "query": {
    "match": {
      "description": {
        "query": "quick brown fox",
        "minimum_should_match": "75%"
      }
    }
  }
}

复合查询优化

优化复合查询结构：

• 使用bool查询组合多个条件，将最能过滤的条件放在filter子句中
• 尽量减少must_not查询的使用
• 避免深层嵌套的bool查询

# 优化复合查询
GET my_index/_search
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "status": "published" } },
        { "range": { "date": { "gte": "now-1y" } } }
      ],
      "must": {
        "match": { "title": "elasticsearch optimization" }
      }
    }
  }
}

正确使用Filter和Query可以显著提高查询性能：

Filter上下文

Filter上下文的特点：

• 不计算相关性分数，性能更高
• 结果可被缓存，重复查询更快
• 适合精确匹配、范围条件等yes/no判断

Query上下文

Query上下文的特点：

• 计算文档与查询的相关性分数
• 性能较Filter略低
• 适合全文搜索等需要相关性排序的场景

最佳实践

合理使用Filter和Query：

• 将所有精确条件（如状态、类型、日期范围等）放入bool.filter中
• 只将需要计算相关性的条件（如全文匹配）放入bool.must中
• 先使用filter过滤大部分不匹配文档，再用query计算剩余文档的分数

# 优化前
GET my_index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } },
        { "term": { "status": "published" } },
        { "range": { "date": { "gte": "now-1y" } } }
      ]
    }
  }
}

# 优化后
GET my_index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } }
      ],
      "filter": [
        { "term": { "status": "published" } },
        { "range": { "date": { "gte": "now-1y" } } }
      ]
    }
  }
}

聚合查询可能是ElasticSearch中最消耗资源的操作，合理优化至关重要：

减少聚合数据量

限制参与聚合计算的数据量：

• 使用filter聚合包装其他聚合，先过滤再聚合
• 设置合适的size参数，特别是对terms聚合
• 使用search_after或composite聚合处理大规模结果集

# 使用filter聚合优化
GET my_index/_search
{
  "size": 0,
  "aggs": {
    "published_docs": {
      "filter": { "term": { "status": "published" } },
      "aggs": {
        "avg_rating": {
          "avg": { "field": "rating" }
        }
      }
    }
  }
}

聚合字段优化

优化用于聚合的字段：

• 确保聚合字段启用了doc_values（默认开启）
• 对于keyword字段，考虑使用eager_global_ordinals优化高基数字段
• 对于数值型聚合，可以使用histogram代替terms聚合

# 字段映射优化
PUT my_index
{
  "mappings": {
    "properties": {
      "category": {
        "type": "keyword",
        "eager_global_ordinals": true
      }
    }
  }
}

分布式聚合优化

对分布式环境中的聚合进行优化：

• 使用shard_size参数（通常设置为size * 1.5或更高）
• 考虑使用近似聚合如cardinality而非精确计数
• 对于时间序列数据，使用基于日期的索引可以减少每次查询扫描的分片数

# 使用shard_size优化terms聚合
GET my_index/_search
{
  "size": 0,
  "aggs": {
    "popular_categories": {
      "terms": {
        "field": "category",
        "size": 10,
        "shard_size": 20
      }
    }
  }
}

限制嵌套聚合深度

深度嵌套的聚合会指数级增加计算复杂度：

• 尽量减少聚合嵌套层级
• 每层聚合尽量减少桶数量
• 考虑拆分复杂聚合为多个简单查询

处理大结果集时，选择合适的分页策略至关重要：

传统分页的问题

传统from/size分页存在的问题：

• 深度分页（high from values）会消耗大量内存和CPU
• 性能随着分页深度线性下降
• 默认最多返回10,000条结果（可通过index.max_result_window调整）

Scroll API

适用于需要处理大量数据的场景：

• 创建一个带有时间窗口的搜索上下文
• 适合"一次性"数据导出或后台处理
• 不适合实时用户界面分页

# 初始scroll请求
GET my_index/_search?scroll=1m
{
  "size": 100,
  "query": {
    "match_all": {}
  },
  "sort": ["_doc"]
}

# 后续scroll请求
GET _search/scroll
{
  "scroll": "1m",
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAD1kWTVNJQ1JvV..."
}

Search After

适用于深度分页场景：

• 基于上一页最后一个文档的排序值继续检索
• 无状态操作，不需要维护scroll上下文
• 需要客户端记住上一次查询的最后一个文档的排序值
• 适合"无限滚动"分页模式

# 第一页查询
GET my_index/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "sort": [
    {"date": "desc"},
    {"_id": "asc"}
  ]
}

# 后续页查询(使用上一页最后一个文档的排序值)
GET my_index/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "search_after": ["2021-05-20T05:30:04.832Z", "doc_42"],
  "sort": [
    {"date": "desc"},
    {"_id": "asc"}
  ]
}

Point in Time (PIT)

ElasticSearch 7.10引入的新特性：

• 创建数据快照，确保分页期间数据一致性
• 与search_after结合使用效果最佳
• 比scroll API更轻量，更适合实时用户界面

# 创建PIT
POST my_index/_pit?keep_alive=1m

# 使用PIT和search_after
GET _search
{
  "size": 10,
  "pit": {
    "id": "pit_id_from_previous_response", 
    "keep_alive": "1m"
  },
  "search_after": ["2021-05-20T05:30:04.832Z", "doc_42"],
  "sort": [
    {"date": "desc"},
    {"_id": "asc"}
  ]
}